home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19950929-19951130
/
000168_news@columbia.edu_Sat Oct 21 15:20:22 1995.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
2KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05983
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sat, 21 Oct 1995 11:20:30 -0400
Received: by apakabar.cc.columbia.edu id AA25781
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 21 Oct 1995 11:20:28 -0400
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problem with remote host command
Date: 21 Oct 1995 15:20:22 GMT
Organization: Columbia University
Lines: 35
Message-Id: <46b33m$p5j@apakabar.cc.columbia.edu>
References: <jaypeeDGsB4x.87y@netcom.com>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <jaypeeDGsB4x.87y@netcom.com>,
John Peterson <jaypee@netcom.com> wrote:
> I'm trying to issue a "remote host ..." command from a UNIX SVR4 system
>[under release C-Kermit 5A(190)] to an OS/2 system [running C-Kermit 5A(191)
>in server mode]. The remote process on the OS/2 system takes a non-trivial
>period of time to execute. (Specifically a ghostscript process, that takes
>about 4-5 minutes). The UNIX kermit seems to send NAKs too often, and
>eventually I get the message:
>
> ?Sent too many NAKs
>
>I was under the impression that issuing a "set server timeout 0" would
>disble the NAKs to the server, but it doesn't seem to help at all. I tried
>huge values like 1000000000 too, and the results are no different. What am
>I missing here?
>
No, it's not SET SERVER TIMEOUT. That governs the behavior of the server
when it is waiting for a command from the client.
In this case, the server *has* received a command from the client and has
started an inferior process, and is blocked waiting for the process to
complete (or to send output, which ghostscript is evidently not doing,
since it is busy painting the OS/2 screen). Meanwhile, the *client* is
waiting for a reply and none is coming. Of course the server has no idea
how long the "host" command will take, so it has no way of telling the
client.
So in this case you have to adjust the client, using "set send/receive
timeout" and/or "set retry".
It would not be unreasonable to expect the server to send some kind of
periodic "hold on, I'm working" type of message to avoid this type of
situation; perhaps this can be added in some future release.
- Frank